IP Security (IPsec) standard, IP Security Internet Engineering Task Force (IETF) Request for Comments (RFC) 2401, published November 1998, represents a known method of protecting both the confidentiality and integrity of data transferred on a network. Because IPsec provides a way to encrypt and decrypt data below the Transmission Control Protocol (TCP)/User Datagram Protocol (UDP) layer, the protection is transparent to applications that transfer data. Thus, a system may utilize IPsec without requiring changes at the application level. However, the algorithms used for cryptography (crypto) operations, for example, encryption, decryption, and authentication on the data for IPsec require many processor cycles to execute. The processor cycles spent on executing crypto operations on received packets in a traffic stream decrease the number of available processor cycles for applications and other parts of the protocol stack. This in turn can decrease the total throughput of the system.
One solution to this problem is to offload the crypto operations to external hardware, such as a Network Interface Card (NIC). One way to offload the crypto operations is by encrypting data immediately before transmitting packets and decrypting data directly upon receipt before the packets are transferred via Direct Memory Access (DMA) to host memory. A Security Association (SA) is a data structure of cryptography information that contains all of the information necessary to perform crypto operations on a packet. The device that interfaces the system to the network, for example a NIC, detects which SA is needed to process the packets and performs crypto operations on the packets directly upon receipt. The process for decrypting and authenticating ingress data before it is transferred to host memory is called “Inline Receive.”
An alternative to Inline Receive is to offload using a “Secondary Use” model. This model uses an out-of-band acceleration method to decrypt received packets. In this model, all received packets in a traffic stream are DMA-transferred to host memory. The network interface driver then parses each received packet to match it with its corresponding SA. Assuming that the crypto accelerator is on the NIC, the driver then instructs the NIC to transfer the packet back to host memory.
Secondary Use results in inefficient use of the available bandwidth on the system bus, because the packet is transferred across the bus three times. Secondary Use also creates additional latency, which can degrade the throughput of protocols sensitive to the round-trip time of packets, for example, TCP. Furthermore, performing extra transfers across the bus often requires the use of additional interrupts, causing the system to do more work, and increasing CPU utilization. From a performance perspective (both CPU utilization and throughput), Inline Receive is preferable to Secondary Use.
However, an Inline Receive function is expensive to implement in hardware, because the keys and matching information for crypto operations typically must be stored on the NIC in an SA cache. Because of this, currently available equipment only supports a limited number of connections that can use Inline Receive. It is common for the number of open connections to exceed the size of the Inline Receive cache. In such situations, other connections have to use the Secondary Use model in order to offload secure traffic. A traditional approach is to add SAs to the Inline Receive cache on a first-come, first-served basis. Under the traditional approach, packets associated with SAs in the cache will be handled using Inline Receive. When there are no available entries in the cache, packets for non-cached SAs must be handled using Secondary Use to process the packets. In some cases, using software instead of Secondary Use to process the packets may yield better performance.
Inline Receive is a preferred method for processing packets but, as mentioned above, Inline Receive can only be used for a limited number of connections. Also, Inline Receive cannot support all packet formats due to hardcoded design. In such and other similar situations, current techniques do not determine which of multiple IP security offloading techniques to use for crypto operations when Inline Receive is not available to improve system performance.